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Abstract.  Safety  of  interoperation  of  program  fragments  written  in  different  safe 
languages  may  fail  when  the  languages  have  different  systems  of  computational 
effects:  an  exception  raised  by  an  ML  function  may  have  no  valid  semantic  in¬ 
terpretation  in  the  context  of  a  Safe-C  caller.  Sandboxing  costs  performance  and 
still  may  violate  the  semantics  if  effects  are  not  taken  into  account.  We  show  that 
effect  annotations  alone  are  insufficient  to  guarantee  safety,  and  we  present  a  type 
system  with  bounded  effect  polymorphism  designed  to  verify  the  compatibility 
of  abstract  resources  required  by  the  computational  models  of  the  interoperating 
languages.  The  type  system  ensures  single  address  space  interoperability  of  stat¬ 
ically  typed  languages  with  effect  mechanisms  built  of  modules  for  control  and 
state.  It  is  shown  sound  for  safety  with  respect  to  the  semantics  of  a  language 
with  constructs  for  selection,  simulation,  and  blocking  of  resources,  targeted  as 
an  intermediate  language  for  optimization  of  resource  handling. 


1  Introduction 

Component-based  software  development  promises  the  freedom  to  choose  the  most  suit¬ 
able  language  independently  for  each  fragment  in  a  system,  as  long  as  the  language 
implementation  supports  a  common  interface  [12,  15].  The  existing  interfaces  offer  a 
trade-off  between  safety  and  efficiency  of  interlanguage  communication.  The  commu¬ 
nicating  programs  may  reside  in  separate  address  spaces,  delegating  the  responsibil¬ 
ity  for  correctness  of  their  interaction  to  the  operating  system,  which  imposes  severe 
performance  penalties  even  for  components  using  the  same  language  implementation. 
Alternatively  the  caller  and  callee  may  share  the  same  address  space;  this  provides  for 
fast  interaction  but  typically  fails  to  prevent  possible  errors  due  to  inconsistency  of  the 
computational  models.  With  the  increasing  dependence  on  component  libraries  the  ef¬ 
ficiency  of  the  interoperation  mechanism  is  becoming  a  significant  factor;  on  the  other 
hand  the  use  of  third-party  components,  especially  in  the  context  of  dynamic  linking, 
requires  strong  safety  guarantees. 
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Interoperation  between  fragments  with  different  computational  models  also  occurs 
when  a  higher-level  language  is  being  used  for  systems  programming.  Demands  for 
independence  of  some  language  features  (e.g.  garbage  collection  [11])  on  parts  of  the 
system  can  be  satisfied  by  compiling  them  using  a  different  model  for  a  subset  of  the 
language,  and  using  an  interlanguage  protocol  to  communicate  with  the  rest  of  the  sys¬ 
tem.  This  approach  can  also  be  used  when  compiling  finer-grained  program  fragments 
written  in  the  same  language,  to  achieve  pay-as-you-go  efficiency  of  language  features 
using  the  most  cost-effective  model  which  supports  the  features  employed  by  the  par¬ 
ticular  fragment.  On  a  higher  level,  different  source  languages  may  have  a  common 
representation  in  a  typed  intermediate  language  [16]  and  different  but  interoperating 
implementation  schemes,  tuned  to  specific  source  language  characteristics.  Safety  and 
efficiency  of  interoperation  are  again  definite  but  competing  requirements  in  these  situ¬ 
ations. 

To  provide  the  basis  for  a  safe  and  efficient  interlanguage  operation,  in  this  paper 
we  describe  a  novel  type -based  technique,  supporting  principled  interoperation  among 
languages  with  different  features  selected  among  mutable  store,  exceptions,  first-class 
continuation,  and  heap  and  stack  allocation  of  activation  records.  Our  framework  allows 
programs  written  in  multiple  languages  with  overlapping  features  to  interact  with  each 
other  safely  and  reliably,  yet  without  restricting  the  expressiveness  of  each  language. 
Thus  our  goal  is  designing  an  interoperability  scheme  which  is 

-  safe:  it  should  not  be  possible  to  violate  the  runtime  safety  of  a  language  by  call¬ 
ing  a  foreign  function,  even  if  this  function  is  defined  in  a  language  with  different 
features;  and 

-  efficient:  a  language  implementation  should  not  be  forced  to  use  suboptimal  meth¬ 
ods  for  its  own  features  in  order  to  provide  support  for  other  languages’  features. 
For  instance  the  implementation  of  a  language  that  does  not  have  exceptions  should 
not  have  to  know  about  the  exception  handling  mechanism(s)  used  in  interoperating 
implementations  of  other  languages. 

Ideally  we  would  like  to  have  complete  interoperability,  allowing  us  to  invoke  any 
function  from  any  term  written  in  another  language  as  long  as  the  semantics  of  this 
invocation  is  defined  in  the  “union”  of  the  languages.  However  this  requirement  poses 
serious  efficiency  problems,  since  to  satisfy  it,  the  implementation  of  each  language 
should  be  aware  of  the  supporting  mechanisms  for  all  features  in  the  union  language. 
Thus,  for  instance,  if  a  Scheme  implementation  S  employs  heap-based  allocation  of 
activation  records,  an  implementation  of  Safe-C  which  may  have  to  interoperate  with  S 
cannot  use  a  stack;  or,  conversely,  the  Scheme  implementations  will  be  forced  to  use  an 
allocation  strategy  compatible  with  a  stack  [1,  5], 

At  the  other  extreme  are  interfaces  like  COM  [15]  which  impose  few  restrictions 
on  language  implementations.  Safety  is  to  be  ensured  via  sandboxing,  using  separate 
address  spaces.  The  interoperation  mechanism  supports  only  basic  language  features, 
e.g.  function  invocation  and  passing  of  arguments  and  result.  In  cases  when  the  cost 
of  cross-domain  calls  is  acceptable  this  appears  as  a  reasonable  solution,  but  in  fact 
depending  on  design  choices  in  the  implementations  it  may  not  provide  the  expected 
semantics. 


ML: 

exception  E 

fun  callback  ()  =. . .  raise  E  . . . 
fun  MLMain  ()  = 

J.f  (0, callback) 

handle  E  =>  J.f  (1, callback) 

> 

> 


Java: 

class  J  { 

public  static 

void  f  (int  i.  Callback  c) 
throws  Exception  { 

if  (i  ==  1)  throw  new  ExceptionO  ; 

try  {  c . invoke  ();  } 

catch  (Exception  e)  {  ...  } 


Fig.  1.  Failure  of  simple  sandboxing  to  preserve  semantics 


Consider  the  schematic  example  shown  in  Figure  1,  where  raising  exception  E  in 
callback  shortcuts  the  flow  through  the  Java  fragment.  If  the  Java  implementation 
maintains  information  about  the  last  entered  try  (i.e.  the  current  exception  handler) 
which  is  context-switched  upon  calls  to  ML,  this  information  will  be  incorrect  (with 
respect  to  the  “union”  semantics)  when  Exception  is  thrown  after  the  second  call  to 
J.f. 

Thus  as  observed  in  [14]  the  function  of  a  mechanism  for  safe  interlanguage  calls  is 
more  than  marshalling  values  between  representations  -  it  must  also  take  into  account 
the  effect  systems  of  the  languages. 

The  contribution  of  this  paper  is  that  it  formalizes  the  notion  of  safe  interoperabil¬ 
ity  between  statically  typed  languages  by  building  on  previous  work  on  effect  sys¬ 
tems  [8,  18,  19]  and  introducing  a  type  system  which  relates  effects  to  the  machine 
resources  they  require.  Since  different  models  of  languages  provide  different  sets  of 
resources,  and  the  same  effect  may  be  possible  with  various  sets  of  resources,  both  an 
effect  and  a  resource  annotation  are  needed:  the  resource  annotation  indicates  the  spe¬ 
cific  requirements  of  a  code  fragment,  while  the  effect  annotation  determines  whether 
an  alternative  set  of  resources  can  be  coerced  to  match  these  requirements. 

Tracking  the  effects  of  the  parameters  of  higher-order  functions  is  achieved  by  effect 
polymorphism:  using  effect  variables  in  the  types  to  express  the  dependencies.  More 
specifically  our  system  has  bounded  effect  polymorphism  to  reject  effect  applications 
when  the  effect  arguments  are  unsupported  by  the  resource  bounds.  We  omit  type  poly¬ 
morphism  from  the  present  description  for  brevity;  we  believe  it  is  largely  orthogonal 
to  the  treatment  of  resources  and  effects  in  types. 

Furthermore,  to  show  soundness  of  our  type  system,  we  introduce  a  typed  language 
with  constructs  for  explicit  management  of  machine  resources.  Using  this  language  as 
intermediate  in  compiling  various  source  languages  allows  the  compiler  to  optimize 
interlanguage  calls  by  “floating”  the  boundary  between  contexts  with  different  resource 
requirements.  Thus  parts  of  a  program  written  in  one  language  can  be  specialized  to 
operate  with  the  resources  provided  by  the  implementation  of  another  language  [17]. 

The  result  is  that  our  system  avoids  the  safety  traps  and  allows  for  the  interoperation 
of  efficient  implementations  by  restricting,  in  some  cases,  which  foreign  functions  may 
be  invoked,  and  imposing  conditions  the  caller  must  satisfy  before  the  invocation.  To 
determine  whether  a  call  is  possible,  we  consider  the  effects  of  a  function,  i.e.  its  use  of 


Fig.  2.  Language  interoperation:  conditions  for  safety  and  efficiency 


resources.  A  resource  has  to  be  saved  (blocked)  when  it  is  not  required  by  the  callee.  If 
a  resource  which  the  caller  does  not  have  is  needed  by  the  called  function,  but  the  latter 
does  not  produce  an  effect  depending  on  this  resource,  a  dummy  resource  can  be  pro¬ 
vided  instead.  In  some  cases  it  is  possible  to  switch  to  alternative  resources  supporting 
the  same  effect.  An  example  illustrating  these  points  is  shown  in  Figure  2  where  three 
languages  Li,  L2,  and  L3  are  built  out  of  the  semantic  modules  studied  in  this  paper. 
For  example,  calling  an  L3  function  from  an  L2  program  is  always  possible,  because  the 
functionality  of  all  resources  of  L3  is  supported  in  L2,  but  the  calling  convention  must 
be  switched  from  heap  to  stack  based,  and  the  L2  exception  handler  must  be  preserved. 

To  specify  formally  and  prove  the  safety  of  our  system,  in  Section  2  we  introduce 
the  typed  intermediate  language  TZ  and  describe  its  static  and  dynamic  semantics  in  Sec¬ 
tion  3.  In  Section  3.3  we  show  that  the  type  system  of  7 Z  guarantees  the  runtime  safety 
of  type-correct  programs.  This  makes  possible  the  safe  linking  of  separately  compiled 
components  which  can  be  shown  to  have  a  type-correct  translation  into  1Z  with  the 
corresponding  interface  type. 

2  A  Language  with  Machine  Resource  Control 

The  language  TZ  is  an  idealized  version  of  the  typed  intermediate  language  of  our  sys¬ 
tem.  The  novel  feature  in  it  are  the  abstract  resources,  which  together  with  their  associ¬ 
ated  primitive  operations  can  be  seen  as  modules  of  which  we  can  build  sublanguages 
of  7 Z:  indeed  this  is  an  implied  goal  of  our  interoperability  scheme.  Both  the  static  and 
the  dynamic  semantics  of  7Z  permit  a  presentation  in  which  new  functional  blocks  are 


Abstract  Resources 

-  CONTINUATION 


ContRes  3  a 

:= 

S  |  H 

continuation  stack  and  heap 

-  CONTROL 

CtrlRes  3  c 

:= 

a  |  X 

. . .  plus  an  exception  handler 

-  PRIMITIVE 

PrimRes  3  r 

:= 

c  |  M 

. . .  plus  a  mutable  store 

Resource  Descriptors 

P 

G 

ResourceDesc  =  CtrlRes  x  2Pr,mRe 3 

Effects 

u 

G 

EffVar 

PrimEff  3  f 

:= 

callcc  |  exception  | 

store 

£ 

G 

Effects  =  2EffVarUPrimEff 

Types 

Typ  3  t  : 

:= 

t  -3%  t  |  contp[r] 

Vll<p.T 

i 

exn  |  ref[r]  |  unit 

b,  b  G  BasicTyp 

Values  and  Terms 

Val  3  v 

:= 

x  |  d 

x  G  Var ,  d  G  Const  O  {*} 

i 

A p  x\T.e 

resource-specific  abstractions 

i 

Au<p.v 

bounded  effect  abstractions 

i 

x[e] 

effect  applications 

Exp  3  e : 

:= 

@  X  x' 

applications 

1 

use  ( p )  e 

resource  control 

1 

M 

values 

1 

let  x  :  t  <—  e  in  e' 

bindings 

1 

ref  x  |  !  x  \  x:=x 

store 

1 

callcc  x  |  throw[r] 

x  x'  continuations 

1 

e  handle  x  :  exn.  e' 

|  raise[r]  x  exceptions 

Fig.  3.  Syntax  of  1Z,  a  language  with  typed  resource  control 


added  to  a  basic  language  without  interference  with  other  blocks;  the  exception  is  the 
exceptions  block,  whose  semantics  needs  support  from  both  first-class  continuations 
(when  present)  and  the  resource  handling  itself.  We  take  the  approach  of  presenting  all 
blocks  in  one  step  mainly  due  to  space  constraints. 

The  abstract  resources,  ranged  over  by  r  (see  Figure  3),  are  structured  in  a  hier¬ 
archy  including  the  control  resources  c  and  their  subdivision,  the  continuation  alloca¬ 
tion  resources  a.  The  language  supports  two  allocation  strategies  for  activation  records: 
a  stack-based  discipline  with  abstract  resource  S,  and  a  heap-based,  with  abstract  re¬ 
source  H.  An  additional  control  resource  is  the  exception  handler  X.  Informally  all  of 
the  control  resources  can  be  viewed  as  structures  of  frames  such  as  activation  records. 
A  primitive  resource  not  related  to  the  control  is  the  store  M ;  the  system  can  be  directly 
extended  with  multiple  versions  of  the  store  which  can  be  controlled  separately. 

Primitive  resources  are  the  building  blocks  of  the  resource  descriptors  p,  consisting 
of  two  components.  The  first  component  specifies  the  “calling  convention”  in  use.  i.e. 


how  values  are  communicated  to  and  from  a  term;  to  keep  the  system  simple  we  only 
consider  conventions  on  returning  the  result,  with  a  choice  between  a  stack-allocated 
and  a  heap-allocated  continuation.  The  second  component  describes  the  set  of  resources 
available  or  required  for  the  evaluation  of  a  term. 

The  counterpart  of  resources  are  the  effects  e  which  are  sets  of  primitive  effects  (in¬ 
formally  caused  by  the  corresponding  primitive  operations  in  the  language)  and  effect 
variables  which  stand  for  sets  of  effects.  In  our  language  the  primitive  effects  are  callcc, 
exception,  and  store.  A  computation  may  only  introduce  effects  which  are  provided  for 
by  the  available  resources,  e.g.  the  effect  exception  can  only  occur  when  the  exception 
handler  resource  X  is  available. 

There  are  only  minimal  requirements  for  resources  needed  to  produce  an  effect; 
extra  resources  can  simply  be  ignored.  This  intuitive  observation  leads  to  the  definition 
of  a  relation  of  compatibility  between  resource  descriptors:  letting  rs  range  over  sets 
of  primitive  resources,  (a,  rs)  C  (a,  rs')  if  rs  C  rs' .  Note  that  compatible  resource 
descriptors  denote  the  same  calling  convention. 

The  types  r  include  function  types  iq  —A'  72  annotated  with  a  resource  descriptor  p 
and  effects  e.  This  notation  describes  a  function  whose  evaluation  requires  the  calling 
convention  and  resources  denoted  by  p,  and  produces  the  effects  e.  Similarly  the  re¬ 
source  annotation  p  on  the  type  of  continuations  contp[r]  denotes  the  resources  needed 
to  re-activate  the  continuation;  the  type  system  assumes  that  the  effect  of  invoking  a 
continuation  is  the  maximal  possible  under  p. 

Among  the  types  are  also  the  bounded-effect  quantified  types  Mu  <  p.  r.  An  effect 
application  x[s\  of  a  variable  x  of  this  type  is  only  valid  when  the  effects  e  are  possible 
with  the  resources  described  in  p. 

In  addition  to  effect  applications  the  values  v  of  7 Z  include  bounded  effect  abstrac¬ 
tions,  and  abstractions  annotated  with  resource  descriptors  with  the  meaning  noted  for 
function  types  above. 

A  term  e  which  requires  the  resources  described  in  p  and  produces  effects  £  can  be 
visualized  as  the  element  shown  in  Figure  4(a),  where  the  S  indicates  the  convention  for 
the  result  is  to  use  a  stack.  The  term  \v\  denotes  an  effect-free  computation  returning 
the  value  v  according  to  a  convention  determined  by  the  context.  The  computation  of 
let  x  :  r  <—  e  in  e'  merges  the  effects  of  the  computations  of  e  and  e'  with  x  bound  to 
the  value  of  e  (Figure  4(b)). 


resources 


effects  and 
resources 


result 


(a)  A  term  requiring  resources  p 
and  producing  effects  e 


(b)  Evaluation  of  let  X  :  T  4—  e  in  e' 
with  resources  p 


Fig.  4.  Terms  and  their  composition 


p’ 

rv'p? 

e 

9  H]  )  1 

e 

B  _ JjL) 

(a)  restricting  (b)  extending 

the  set  of  resources 


(c)  switching  calling  conventions 


Fig.  5.  Operations  on  resources  performed  by  use  ( p )  e 


A  novelty  is  the  resource-management  construct  use  ( p )  e,  which  evaluates  e  in  the 
context  of  resources  described  by  p,  replacing  the  current  resources.  For  instance,  it 
is  possible  to  reduce  the  set  of  available  resources  p'  when  a  term  e  expects  a  subset 
p  (as  reflected  in  its  type,  see  Section  3  for  details).  As  alluded  to  in  Figure  5(a),  the 
resources  currently  available  but  not  needed  are  preserved  during  the  evaluation  of  e 
and  restored  upon  completion.  For  example,  consider  the  case  of  an  ML  program  with 
resources  (H,  {H,  X,  M})  invoking  a  Scheme  function  f  with  an  integer  argument  x  and 
integer  result.  Assuming  both  implementations  perform  heap  allocation  of  activation 
records,  the  call  would  require  preserving  the  ML  exception  handler.  Translated  to  1Z, 
the  invocation  is  expressed  by 


use  ({H,  {H,  M}))  (@  f  x) 

in  a  type  environment  including  x  :  Int,  f  :  Int  — >|HTH>M}>  |nt  (for  some  effect  s). 

It  is  also  useful  to  allow  the  creation  of  a  new  dummy  resource  r  when  it  is  re¬ 
quired  by  a  term  e  but  the  effects  of  e  make  no  use  of  r.  Consider  a  Scheme  frag¬ 
ment  with  resources  (H,{H,  M})  invoking  a  compiled  from  ML  function  g  of  type 
Int  — ^{store}X'M^  This  type  shows  that  g  has  no  effects  that  require  the  exception 

handler,  but  the  code  for  g  nevertheless  expects  an  exception  handler  resource,  which 
is  reflected  in  the  resource  component  of  g’s  type.  Therefore  the  invocation  must  be 
enclosed  in  a  use,  constructing  a  dummy  X  resource: 

use  ((H,  {H,  X,  M})  (@  g  5) 

This  situation  is  represented  graphically  in  Figure  5(b)  where  the  effects  e  are  supported 
by  the  resources  p' ,  but  the  term  e  requires  additional  resources. 

In  the  absence  of  continuation  capture  effects  the  creation  of  new  stack  and  heap 
resources  has  different  semantics  due  to  the  localization  of  allocation  effects  on  these 
resources.  While  a  newly  created  store  or  exception  handler  resource  cannot  be  used 
at  all  (since  any  use  would  create  an  effect  which  requires  that  resource,  hence  the 
term  would  not  have  a  type  in  an  environment  which  does  not  provide  the  resource), 
a  new  stack  or  heap  may  be  used  for  the  allocation  of  activation  records,  because  the 
allocation  effect  is  localized  and  will  not  be  propagated  when  the  evaluation  of  the 
term  is  completed.  Note  that  this  only  applies  to  the  use  of  the  heap  for  stack-like 
management  of  activation  records;  use  of  callcc  for  instance  introduces  an  effect  which 


let  id  :  r  — t  4—  LA"4  x :  7-.  |_xJ  J 

in  let  wrap  :  Vu  <  Both,  (r  — >u  r)  — >B  r  — >u  r 

4—  [Au  <  Both. 

\B  f:r  — >u  t.  [X bx:t. 

use  ( Either ) 

use  (T)  (@  f  x)JJ 

in  let  throw42  :  r  — >^caNccj  Int 

4— [As  k:r.  let  id_H  :  (r  — >B  r)  4—  @(wrap[0])id 

in  let  k’  :  r  4—  @  id_H  k 
in  let  x  :  Int  4—  |_42J 

in  throw[lnt]  k'  xj 


where 

r 


A 

B 

Either 

Both 


in  callcc  throw42 


contB[lnt] 

(S,{S,M}> 
(H,{H,M}> 
{H,  {S,  H,  M}) 


Fig.  6.  Example  of  handling  of  foreign  objects 


makes  it  impossible  to  type  the  term  in  an  environment  which  does  not  have  a  heap 
resource. 

Another  application  of  the  construct  use  ( p )  e  is  the  selection  of  calling  convention. 
Figure  5(c)  illustrates  this  in  the  case  of  switching  from  stack-based  to  heap-based  con¬ 
tinuations  for  the  evaluation  of  e  when  p  =  { H ,  rs )  and  the  resource  descriptor  of  the 
context  is  p1  =  (S,  rs),  where  { H ,  S}  C  rs  (i.e.  both  a  heap  and  a  stack  are  provided). 
Formal  conditions  for  validity  of  use  (p)  e  are  presented  in  Section  3. 

The  example  in  Figure  6  shows  an  application  of  use  in  the  case  of  interoperation 
between  programs  written  in  two  languages.  The  function  id  uses  stack  allocation  (S), 
while  throw42  uses  heap  allocation  ( H).  Both  languages  also  have  the  store  resource  M. 
Before  id  can  be  called  from  throw42,  it  must  be  coerced  to  heap  allocation,  which  is 
performed  by  the  effect-polymorphic  function  wrap.  Note  that  the  effects  of  the  argu¬ 
ments  of  wrap  are  restricted  by  the  resources  in  the  intersection  of  the  two  languages’ 
sets,  denoted  by  Both',  in  this  case  this  means  only  store  effects  are  allowed.  The  in¬ 
vocation  of  wrap's  argument  f  is  enclosed  in  two  use  regions:  the  outer  use  creates  a 
new  stack,  while  the  inner  one  switches  the  calling  convention  to  the  stack  and  saves 
the  heap  resource. 

The  example  also  shows  how  an  object  which  only  has  meaning  in  a  language  with  a 
given  feature  can  be  handled  “passively”  by  code  written  in  a  language  without  support 
for  that  feature.  Note  that  the  first-class  continuation  captured  in  the  heap-allocating 
program  is  passed  to  id  and  back,  and  then  activated. 


Effect  Environment  Formation 

Type  Environment  Formation 

(Env-eff-empty) 

hd  0 

(Env-efF-ext) 

\~A  A 

(Env-typ-empty) 
hd  A 

hi  At,  t  <  p 

A  hr  0 

Effects 

(Eff-empty) 

(Eff-union) 

(Env-typ-ext) 

A  hr  r  A  hT  t 

\~A  A 

A  h  s'  <  p  A  h  e"  <  p 

A  hr  Tx,  x  :  t 

A  he  0  <  p 

A  he  s'  U  e"  <  p 

(Eff-var) 

\~a  A  u  6  Dom  (A) 
A  he  u  <  A(u) 

(Eff-primitive) 

h a  A  p  G  Required  (/) 

^  h  {/}  <  p 

Values 

(Val-const) 

A  hr  r 

A-,T  hvd:9{d) 

(Eff-add-resource) 

A  he  <  p  pE p 

A  h  e  <  p 

Types 

(Val-var) 

A  hr  r  x  G  Dom  (F) 

A;  r  hv  x  :  r(x) 

(Typ- basic) 

F a  A 

(Typ-fun) 

A  he  e  <  p  A  hT  T,  T 

(Val-abs) 

A  hr  r  A  hT  t 
p\A\Fx,  x  :  t  he  e  :  r';e 

A  hT  b 

A  hT  T  ~ >Pe  T 

A;F  hv  \p  x:t.  e  :  t  — >pe  t' 

(Typ-unit) 

hd  ^ 

(Typ-poly) 

hd  A  Au,  U  <  p  hr  T 

(Val-eff-abs) 

A  hr  r  Au,  u  <  p-,r  hv  v  :  t 

A  h-  unit 

A  hr  Vu<p.T 

A;  r  h,  Au  <p.v  :Vu<p.T 

(Typ-ref) 

A  hT  T 

(Typ-cont) 

A  hT  t  0  h  {callcc}  <  p 

(Val-eff-app) 

r(x)  =\/u<p.r  A  he  e  <  p 

A  hT  ref[r] 

A  hT  contp  [r] 

A;  r  h„  aj[e]  :  [e/«]r 

Fig.  7.  The  1Z  type  system:  effects,  types  and  values 


3  Semantics  of  1Z 

3.1  Static  Semantics 

The  type  system  of  R,,  shown  in  Figures  7  and  8,  keeps  track  of  the  resources  necessary 
for  the  evaluation  of  a  term  and  makes  a  conservative  estimate  of  the  effects  of  the  eval¬ 
uation.  The  effect  environment  A  specifies  the  resource  bounds  of  free  effect  variables, 
and  as  usual  the  type  environment  F  assigns  types  to  free  variables. 

The  rules  for  sequents  A  hes  <  p  reflect  the  dependence  of  effects  on  resources  and 
form  the  basis  of  bounded  effect  polymorphism.  The  dependence  of  primitive  effects  on 
resources  is  captured  by  the  function  Required  (Figure  9)  specifying  the  alternatives  for 
minimal  resource  descriptors  enabling  a  primitive  effect.  Note  that  the  exception  and 
store  effects  work  with  either  stack  or  heap  continuation  allocation,  while  the  callcc 
effect  can  only  be  introduced  with  heap  allocation. 


(Exp-app) 

a  hr r  r(x)  —  t'  — t  r{x)  =  T' 

(Exp-use) 

P\  A  r  he  e  :  t;  s  A  he  e  <  p 

p\  A;  r  he  @  x  x  :  t;  e 

(Exp-val) 

A;  r  K ,  v  :  t 

P\A\F  he  |uj  :  r;0 

(Exp-callcc) 

A  hr  r  r(x)  =  contp[r]  — >pe  r 

p  \  A-,r  he  use  (p)  e  :  r;  e 

(Exp-let) 

P',A-,r  he  e  :  t-,e 
p\  A-,rx,  x  :  t  he  e'  :  r';e' 

p-,A-,r  he  let  x  :  r  i —  e  in  e'  :  r';  e  U  e 
(Exp-throw) 

4  hr  r  A  hT  T 
r(x)  =  contp[r']  r{x')  =  r' 

p\  A\  r  he  callcc  x  :  t;eU  {callcc} 

(Exp- ref) 

A  hr  r  r(x)  =  t  A  he  {store}  <  p 

p-,  A;  r  he  throw[r]  x  x  :  r;  MaxEff  (p) 
where  MaxEff  (p)  =  {/  |  0  he  {/}  <  p) 

(Exp-deref) 

A  hr  r  r(x)  =  ref[r]  A  he  {store}  <  p 

p\  A;  r  he  ref  x  :  ref [r];  {store} 

p\A-,r  he  !  x  :  t;  {store} 

(Exp-update) 

A  hr  r  r(x)  =  ref[r]  r(x  )  =  r  A  he  {store}  <  p 

p\  A\  r  he  x  :=  x'  :  unit;  {store} 

(Exp-raise) 

A  hr  T  r(x)  =  exn 

A  he  {exception}  <  p 

p\  A;  r  he  raise[r] 

x  :  r;  {exception} 

(Exp-handle) 

p\A\T  he  e  :  t;  e 

p;A;Fx,x  :  exn  he  e'  :  t; e 

'  A  he  {exception}  <  p 

p ;  A;  r  he  e  handle  x  :  exn. 

e  :  r;  e  U  e  U  {exception} 

Fig.  8.  The  1Z  type  system:  terms 


Type  judgments  for  values  associate  a  type  r  with  a  value  v  and  a  pair  of  environ¬ 
ments;  values  have  no  effects  and  therefore  their  computation  requires  no  resources.  Se- 
quents  for  terms  have  the  form  p;  A;  T  he  e  :  r;  e,  where  p  is  the  resource  descriptor  of 
the  environment,  r  is  the  type  of  e,  and  e  represents  the  effects  of  the  evaluation  of  e.  For 
the  typing  of  constants  we  assume  the  existence  of  a  function  9  €  Const  — >■  BasicTyp, 
and  in  particular  that  $(*)  =  unit. 


Required  (callcc)  =  {{H,  {H})} 

Required  (exception)  =  {{S,{S,X}),  {H,{H,X})} 
Required  (store)  =  {{S,{S,M}),  {H,{H,M})} 


Fig.  9.  Minimal  resource  requirements  for  primitive  effects 


The  function  MaxEff  yields  the  maximal  effect  possible  with  the  resources  in  p\  it 
is  used  in  making  a  conservative  approximation  of  the  effects  of  a  continuation  given 
the  resources  available  at  the  point  of  its  capture  (in  rule  (Exp-throw)). 


3.2  Dynamic  Semantics 

To  separate  the  static  and  dynamic  aspects  of  the  use  of  resource  descriptors  we  consider 
a  variant  of  7 Z  with  explicit  resource  annotations,  where  the  abstract  syntax  for  terms  is 

e  ::=  @  x  x'  |  us ep(p')e 

!  [v\p  |  letp  x  :  t  <-  e  in  e' 
j  refp  x  |  \p  x  |  x  :=p  x' 

|  callccp  x  |  throwp[r]  x  x' 

|  e  handlep  x  :  exn.  e'  |  raisep[r]  x 

The  translation  of  type-correct  1Z  terms  into  the  annotated  language  is  straightforward 
since  the  new  annotations  correspond  to  the  resource  descriptors  p  on  the  left  of  he  in 
the  typing  sequents  for  those  terms. 

We  present  operational  semantics  of  7 Z  following  [3]  in  terms  of  a  variant  of  the 
tail-call-safe  CaEK  machine.  We  prefer  operational  semantics  because  it  allows  us  to 
show  directly  that  reasonably  efficient  implementations  exist.  The  original  machine  al¬ 
locates  an  activation  frame  on  the  continuation  stack  when  entering  a  let-binding  (but 
not  when  entering  a  closure),  and  pops  the  frame  to  complete  the  binding.  We  extend  the 
machine  by  including  a  component  denoting  additional  machine  resources,  and  by  pro¬ 
viding  a  heap-based  alternative  continuation  allocation  strategy  supporting  first-class 
continuations. 

The  transitions  of  the  abstract  machine  are  specified  as  a  relation  on  machine  con¬ 
figurations  consisting  of  the  term  being  evaluated,  its  environment,  and  the  currently 
available  machine  resources;  for  the  purposes  of  the  proof  of  soundness  of  the  type 
system  we  include  in  the  configuration  also  the  type  of  the  evaluated  term  as  well  as 
an  accumulator  of  effects.  Having  the  annotations  in  the  syntax  makes  it  clear  that  the 
although  the  semantics  of  some  constructs  depend  on  what  resources  are  available,  this 
dependence  can  be  resolved  at  compile  time. 

The  semantic  domains  defining  the  meaning  of  the  components  of  the  abstract  ma¬ 
chine  are  listed  in  Figure  10.  As  usual  the  environment  E  maps  variables  to  values 
converted  to  their  internal  representation  as  shown  in  Figure  1 1 .  Values  are  represented 
in  the  environment  as  closures  with  environments  binding  their  free  variables;  no  en¬ 
vironment  for  effect  variables  is  needed  because  effect  instantiation  is  performed  via 
substitution  (Figure  11). 

To  assist  with  the  proof  of  soundness  of  the  type  system  we  instrument  the  opera¬ 
tional  semantics  to  keep  track  of  the  current  control  resource,  the  accumulated  effects 
of  the  evaluation,  and  the  type  of  the  term  being  evaluated.  Further,  the  environment  is 
extended  to  also  record  the  type  of  each  variable;  type  safety  (Femma  1)  implies  that 
all  type  annotations  and  tags  only  used  for  verification  in  the  semantics  may  be  erased 
without  affecting  the  outcome  of  the  evaluation  of  a  correctly  typed  term.  We  use  the 
shorthands  vE(x)  and  ^(x)  for  the  value  and  type  components  of  E{x),  respectively, 


Machine  Configuration 

Config  =  Exp  x  Env  x  CtrlRes  x  MResources  x  Effects  x  Typ 

Environment 

MVal  3  w  ::=  Closure  (v,  E)  |  Cont  k  |  Loc  l  machine  values 

E  €  Env  =  Var  -A  MVal  x  Typ  environment 

Machine  Resources 

Rs  £  MResources  =  ^r,CPrimlie,  fT  ^  Mi?  (r)  separated  sum  of  resource  tuples 
where  MR  (S)  =  CoritStack,  MR( H)  =  ContHeap , 

MR  (M)  =  Store,  MR  (X)  =  Ewt 
Continuation  Allocation  Resources 

Frame  3  F  ::=  Bind  {\p  x :  r.  e,  E,  t')  binding  activation  record 

|  Restore  {r,  MR  (r))  resource  blocking  record 

|  Drop  r  resource  simulation  record 

MContRes 0  3  C°  with  empty c  £  MContRes 0 

is  Empty 0  £  MContRes 0  -A  Boolean 

newFrame 0  £  Frame  x  MContRes 0  -A  MContRes0 

topFrame0  £  (*si?roptt/c)_1[{false}]  — ¥  Frame  x  MContRes0 

-  continuation  stack 

Cont  Stack  3  S  ::=  Halt  |  Frame  {F,  S)  frame  stack 

emptys  =  Halt 

isEmptys  =  [Halt  ha  true,  Frame  {F,  S )  ha  false] 
newFrames  ( F ,  S)  =  Frame  (F,  S) 
topFrames  (Frame  (F,  S ))  =  (F,  S) 

-  continuation  heap 

ContHeap  =  ContLoc  x  ( ContLoc  -A  Frame  x  ContLoc)  x  ContLoc 
where  k  £  ContLoc  continuation  locations 

K  £  ContLoc  -3  Frame  x  ContLoc 

emptyH  =  (k,  0,  k)  for  some  k  £  ContLoc 

isEmptyH  (F,  {k,  K,  ke ))  =  (k  =  ke) 

newPrameH  ( F,{k,K,ke ))  =  {k',K[k'  ha  (F,  k)],ke) 

k'  Dom  ( K )  U  {ke} 
topFrameH  {{k,K,ke))  =  {F,  {k1  ,K,ke)) 

if  K{k)  =  {F,k') 

Exception  Handler  Resource 

Exn  =  ContStack  (denoted  by  superscript  X) 

Mutable  Store  Resource 

l  £  StoreLoc  store  locations 

M  £  Store  =  StoreLoc  -A  MVal 
with  empty M  =  0 

re/M  (w,  M)  =  {£,  M[£  ha  m>]),  l  Dom  ( M ) 
derefM  {£,  M)  =  M{£) 

update M  ((£,w),  M)  =  M[£  ha  w],  l  £  Dom  ( M ) 

Fig.  10.  Semantic  domains  for  the  instrumented  operational  semantics  of  1Z 
7  (x,E)  =  vE(x) 

7  [x[s],  E)  =  7  ([e/u\v,  E')  if  vE(x )  =  Closure  {Au<p.v,  E'),  and  0  Fe  £  <  p, 

7  ( v ,  E )  =  Closure  {v,  E)  for  other  v 


Fig.  11.  Representation  of  values 


and  we  write  E[x  ( w  :  r)]  to  denote  the  extension  of  E  which  assigns  machine 
value  w  and  type  r  to  x. 

The  modularity  of  the  language  blocks  is  supported  in  our  framework  by  the  repre¬ 
sentation  of  machine  resources  Rs  as  a  record  (tuple)  with  a  tag  tag  ( Rs )  €  Resources 
which  yields  the  set  of  the  corresponding  primitive  resources.  The  set  of  possible  val¬ 
ues  of  an  individual  machine  resource  corresponding  to  abstract  resource  r  is  denoted 
by  MR  ( r ).  Thus,  assuming  a  canonical  enumeration  of  resources,  a  tuple  of  resources 
with  tag  rs  is  an  element  of  the  singleton  separated  sum  Srs'e{rs}  Flrers'  MR  (r);  we 
will  denote  this  set  by  MRT  {rs).  The  semantics  make  use  of  two  families  of  total 
functions, 

in3rs-{r}  e  MR  (r)  x  MRT  (rs  —  {r})  — ?  MRT  (rsU{r}) 

Pr°jrs u{r}  e  MRt  (rsU{r})  — ?  MR  (r)  x  MRT  (rs  — {r}), 

indexed  by  a  primitive  abstract  resource  r  and  a  tag  rs,  with  the  intention  that  injrrs_^r  j 
maps  (R,  Rs)  to  the  record  containing  R  and  all  of  Rs ,  and  proj  rrfjU  j T  j  is  its  inverse.  We 

also  use  singlerrs  =  7ti  °projrrs  and  droprrs  =  n2  °projrrs.  The  functions  inj°s  and  inj°s 
(and  similarly  proj )  are  commutative  for  r  ^  r',  {r,  r'}  fl  rs  =  0;  this  commutativity 
allows  the  generalization  of  inj  and  proj  to  the  functions 

inJrl_rs'  €  MRT (rs')x  MRT (rs  —  rs')  —?  MRT (rsUrs') 

Pr°jrL>rs'  e  MRt (rsUrs')  — >  MRT (rs')x  MRT (rs  —  rs'). 

Using  these  functions  we  can  define  natural  liftings  of  operations  linear  in  an  in¬ 
dividual  resource  R  (i.e.  in  whose  type  R  occurs  exactly  once  positively  in  both  the 
types  of  domain  and  codomain,  or  does  not  occur  in  the  domain  type  and  the  codomain 
is  linear  in  R)  to  operations  on  a  record  of  resources  Rs  containing  R:  c.g.  for  fr  € 
SxMR  (r)  — ?  S'xMR(r)  we  define/^  (e)5xn^Grs  MR(r)  — >  5'x[]^n  MR(r) 
by 

&  (s,  Rs)  =  let  (R,  Rs')  =  projrrs  (Rs), 

(s',R')  =  r(s,R) 
in  (s',inj^_{r}  (R',Rs')) 

where  r  €  rs.  With  the  generalized  versions  of  inj  and  proj  this  lifting  extends  to 
functions  on  records  of  resources  as  well. 

For  each  primitive  resource  r  there  is  an  initial  element  emptyr  of  the  algebra  of  the 
corresponding  machine  resource;  these  elements  are  used  in  the  simulation  of  resources 
(rule  (add)  in  Figure  13). 

A  generic  continuation  machine  resource  Cc  (corresponding  to  abstract  control  re¬ 
source  c)  is  described  by  the  four  stack  operations  empty0,  isEmpty0,  newFrame0 ,  and 
topFrame0 ,  where  topFrame0  is  the  inverse  of  newFrame 0  on  non-empty  C° .  We  will 
use  the  more  concise  notation  F  ::°s  Rs  both  for  newFrame°s  (F,  Rs)  and  as  a  pattern 
standing  for  Rs'  when  c  €  rs,  isEmpty°s  (Rs1)  =  false,  and  topFrame°s  (Rs1)  = 
(F,  Rs).  A  section  (F  ::°s  )  stands  for  the  function  mapping  Rs  to  F  ::°s  Rs. 

The  stack-based  implementation  only  provides  the  minimal  functionality;  the  heap- 
based  implementation  can  be  used  for  non-sequential  access  as  well.  Exception  han¬ 
dling  uses  a  separate  continuation  stack. 


Activation  frames  include  a  variant  of  the  standard  binding  frames  [3]  to  record  the 
continuation  completing  a  let-binding  let/a’rs'  x  :  r'  -f-  e'  in  e  after  evaluating  e'. 
The  binding  frame  is  of  the  form  Bind  (\’'a'rs)  x  :  r.  e,  E.  r'),  where  r'  is  the  type  of 
e  in  environment  extended  with  x  :  t,  rs  is  the  set  of  resources  available  for  the 
evaluation  of  the  let,  and  a  is  the  allocation  resource  for  the  evaluation  of  e. 

In  addition  there  are  two  kinds  of  resource  management  continuation  frames.  A 
Restore  frame  indicates  that  a  machine  resource  has  been  saved  and  removed  from  the 
current;  a  Drop  frame  signals  that  a  dummy  resource  has  been  created  and  provided 
to  code  which  only  uses  the  it  locally,  or  not  at  all  (but  has  been  compiled  to  expect 
it).  The  names  of  these  frames  suggest  the  operations  that  must  be  done  to  restore  the 
status  after  the  evaluation  of  the  current  term  has  completed,  i.e.  when  the  frame  is 
encountered  during  unwinding  the  continuation. 

The  relation  of  computation  H-i  on  configurations  is  the  union  of  the  transition 
rules  shown  in  Figures  12  and  13);  the  relation  of  computation  is  the  reflexive  transitive 
closure  of  t-^.  The  transition  rules  are  grouped  in  classes  based  on  the  feature  they 
implement  as  follows. 


Building  block 

Rules 

Figure 

environment 

(app),  (let),  (bind) 

12 

store 

(ref),  (deref),  (update) 

12 

first-class  continuations 

(callcc),  (throw) 

13 

exceptions 

(handle),  (raise) 

13 

(add),  (remove),  (redirect) 

resource  management 

(nop),  (restore),  (drop) 

13 

Notable  among  the  transitions  are  those  for  resource  management  -  they  save  a  re¬ 
source  for  future  use  and  remove  it  from  the  currently  available  set,  create  a  dummy 
resource,  or  select  a  different  continuation.  The  interaction  between  resource  manage¬ 
ment  and  exception  handling  is  non-trivial  because  resources  must  be  restored  when 
exiting  a  use-region  in  any  way.  For  that  reason  first-class  continuations  are  restricted 
to  accept  only  the  resource  set  available  at  point  of  capture;  unlike  them,  exception  han¬ 
dlers  are  allocated  on  a  stack,  thus  it  is  possible  to  allow  exceptions  not  to  be  tied  to 
specific  resources  by  intercepting  them  and  restoring  the  resources. 

Our  implementation  of  exceptions  is  more  realistic  than  the  typical  [23]  which  prop¬ 
agates  exception  packets  through  all  enclosing  terms  whose  evaluations  is  pending.  The 
exception  handler  forms  a  stack  parallel  to  the  continuation  stack  (or  heap).  Raising 
an  exception  (rule  (raise))  creates  an  exception  packet  which  is  processed  like  a  value 
with  continuation  on  the  exception  handler  stack;  the  bindings  on  this  stack,  created 
by  handle,  restore  the  default  continuation.  This  scheme  has  on  overhead  if  exceptions 
are  not  used,  and  overhead  linear  in  number  of  catching  handlers  when  an  exception  is 
thrown. 


3.3  Soundness  of  the  Type  System 

To  prove  soundness  of  the  type  system  we  extend  it  with  rules  for  machine  configura¬ 
tions,  and  prove  that  this  extension  has  the  subject  reduction  and  progress  properties. 


Environment 

(app)  {@  x\  *2,  E,  a,  Rs,  e,  r)  h-h  (e1 ,  E'[x'  (->■  E(x 2)],  a,  Rs,  e,  r) 

where  Closure  x  :t'.  e  ,  E')  =  vE(x  1) 

t'  =  tE(x  2) 

(let)  x  :  t'  <—  e'  in  e,  E,  a,  Rs,  e,  r)  i-ti 

<e',  E,  a,  Bind  {A^’”^  x:t'.  e,E\ FV(e)-{x},T)  ::ara  Rs,  e ,  t') 

(bind)  (H<c’ri),  E,  c,  Bind  {\<a’ra)  x:t.  e  ,  E' ,r')  ::c„  Rs' ,  e,  r) 

(e',  E'[x  !->■  (j(v,E)  :  r)],  a,  Rs' ,  5,  t') 


Store  (rules  valid  when  M  G  rs) 

(ref)  x,  E,  a,  Rs,  s,  r)  1 — i-i 

<|yj<a’rs>,  E[x'  !->■  (Loc  l  :  r)],  a,  Rs' ,  e  U  {store},  r) 
where  r  =  ref[2fe(x)] 

=  ref™  (vE(x),  Rs) 
x'  (f:  Dom  (E) 

(deref)  x,  E,  a,  Rs,  s,  r)  >->i 

{{x'J  (a’rs\  E[x'  !->■  ( deref „  (£,  ijs)  :  r)],  a,  Rs,  e  U  {store},  r) 
where  (Loc  l :  ref[r])  =  E(x) 

x  £  Dom  ( E ) 

(update)  {x  :=i'a,rs'>  x  ,  E,  a,  Rs,  e,  unit)  i-H 

(L*J<a’rs>,  E,  a,  update™  ({£,  vE(x’)),Rs),  eU  {store},  unit) 
where  (Loc  £  :  t)  =  E(x) 

t  =  ref  [tE(x')] 


where  rs  =  tag  (Rs),  a  G 


Fig.  12.  Instrumented  transition  rules,  part  1 


The  interesting  aspect  of  assigning  a  type  to  a  configuration  in  this  system  is  that  some 
of  the  values  in  the  environment  may  refer  to  resources  which  are  currently  inaccessible 
(blocked  by  an  enclosing  use),  which  complicates  the  notion  of  type  correctness.  The 
details  of  the  proof  are  omitted  for  space  considerations. 

The  progress  and  subject  reduction  properties  are  combined  in  the  following  lemma. 

Lemma  1  (Safety).  If  C  =  (e,  E ,  c,  Rs,  e,  t)  and  0  l~c  C  :  To;£o,  then  either 
e  =  (c’rs'>  for  some  value  v  such  that  $-,TE  h Vv  :  t,  and  isEmpty^s  (Rs)  =  true,  or 

there  exists  a  configuration  C1  such  that  C  t->i  C1  and  0  \~c  C1  :  To;  £o- 

(Note  that  the  case  of  a  value  in  an  empty  continuation  covers  both  normal  termination 
of  the  program  and  the  case  of  an  unhandled  exception  propagated  to  the  top.) 

As  a  corollary  we  obtain  soundness  of  the  system. 

Theorem  2  (Soundness).  If  C  =  (e,  E,  c ,  Rs,  e,  t)  and  0  he  C  :  ro;£o,  then  C 
computes  to  a  value,  or  to  an  exception  packet,  or  its  computation  diverges. 


First-class  Continuations  (rules  valid  when  Hers) 

(callcc)  {callcc^H’”^  x ,  E,  Rs ,  H,  e,  r)  i->i 

(e',  f5'[x'  i-a  (Cont  k  :  cont^H’r^[r])],  H,  Rs' ,  e  U  {callcc},  r) 
where  (k,  K,  ke)  =  single }!,  (Rs) 

Rs'  =  if  X  £  rs  then  Rs  else  restoreExn  (H)(i(s) 

vE(x)  =  Closure  (A<H’rj>  x':cont <H’ra)[r].  e  ,  E') 

(throw)  {throw^H’rs^[r]  xi  X2 ,  E,  a ,  Rs,  e,  r)  >-H 

<L*aJ<H’”>.  E,  H,  ((ki,K,ke),  Rs'),  6,  r") 

where  (Cont  ki  :  cont^H’T,'^[r''])  =  E(x\) 

((k,  K,  ke),  Rs')  =  protfs  (Rs) 

Exceptions  (rules  valid  when  X  £  rs) 

(handle)(e  handle^0’"^  x  :  exn.  e' ,  E,  a,  Rs,  e,  r)  r->i  (e,  E,  a,  Rs' ,  e  U  {exception},  r) 

(restoreCont  (a,  Rs)  o  \ 

(Bind  (A^a,rs^  x:exn.  e' ,E\FV ^ety_^,T)  )  o  |  (Rs) 

restoreExn  (a)  J 

(raise)  {raise'“’r3) [r]  x,  E,  a,  Rs,  e,  r)  r->i  { L33} ^X’T-'3'1 ,  E,  X,  Rs,  e  U  {exception},  exn) 


Resource  Management 

(add)  (us e<'a’rs^  ((a,  rs'))  e,  E,  a,  Rs,  e,  t)  >-H 

(use<°’,'sU{r})  ({a,  rs'))  e,  E,  a,  inj)s  (emptyr ,  Drop  r  Rs'),  s,  r) 
where  r  £  rs'  —  rs 

Rs'  =  if  X  ^  rs  then  Rs  else  Drop  r  restoreExn  (a)(Rs) 

(block)  (us el'a’rs'>  ((a,rs'))e,  E,  a,  Rs,  e,  t)  i-H 

(use^a’”l_*r^  (( a,rs'))e ,  E,  a,  Restore  { r,R )  Rs" ,  s,  r) 

where  r  £  rs  —  rs'  —  {a} 

Rs"  =  if  X  rs'  then  Rs  else  Restore  {r,  R)  ::*3  restoreExn  (a)(Rs) 

(R,  Rs')=projr3  (Rs) 

(redirect)  (use^a,''s^  ({o',  rs'))e,  E,  a,  Rs,  s,  r)  >-H 

{use<a'’ra)  ((o',  rs’))e,  E,  o',  Bind  {\<a’Ta)  x:t.  L^bJ <“’->,  E,  r) Rs,  e,  r) 

(nop)  (use^a,,'s^  ({a,rs))e,  E,  a,  Rs,  e,  r)  i-Ai  (e,  E,  a,  Rs,  s,  r) 

(restore)  {LvJ^c’rs\  E,  c,  Restore  { r,R )  ::cra  Rs' ,  s,  r)  i-ti 

{[vi^r3\E,c,injrr3(R,Rs'),e,T) 

where  c  d  rs,  r  rs 

(drop)  (|i>J <c’ri>,  E,  c,  Drop  r  ::{s  Rs' ,  e,  r)  Hi  {LuJ<c,rs),  E,  c,  drop!) 8  (Rs'),  e,  r) 
where  c  £  rs,  r  £  rs  —  {c} 


where  rs  =  tag  (Rs) 

a  £  rs 

restoreExn  (a)(Rs)  =  replace  Resource  (a,  X,  Rs)(Rs) 
restoreCont  (a,  Rs')  =  replace  Resource  (X,  a,  Rs') 
replaceResource  (c,r,  Rs')  =  (Drop  r  ::£s  )  o  (Restore  (r,  single^  (Rs'))  ::{s  ) 

where  tag  (Rs1)  =  rs,  {c,  r}  C  rs 


Fig.  13.  Instrumented  transition  rules,  part  2 


4  Related  Work 


Interoperability  is  a  primary  concern  of  component-based  models  such  as  CORBA  [12] 
and  Microsoft's  COM  [15,  13].  Safety  in  these  systems  is  in  conflict  with  the  perfor¬ 
mance  requirements,  and  even  sandboxing  may  fail  to  provide  correct  semantics  when 
the  effect  systems  of  the  communicating  languages  go  beyond  the  value/store  inter¬ 
face.  In  comparison  our  system  allows  flexible  and  efficient  interoperation  between  lan¬ 
guages  with  different  resources,  and  ensures  safety  by  exposing  the  resource  and  effect 
requirements  in  the  types  of  the  components. 

Foreign  function  call  interfaces  [6,  14]  are  related  in  purpose  but  are  designed  un¬ 
der  the  constraint  to  be  compatible  with  legacy  code  which  is  often  unsafe.  Solutions  to 
this  problem  have  major  impact  on  interoperability  today.  We  do  not  attempt  to  solve 
compatibility  issues  in  the  system  presented  in  this  paper.  Our  design  is  for  interoper¬ 
ability  between  safe  components  with  language-independent  interfaces,  aimed  to  satisfy 
high  performance  requirements  when  running  in  shared  address  space.  We  emphasize 
building  a  safe,  efficient,  and  robust  interface  across  multiple  HOT  languages. 

The  present  work  extends  our  earlier  results  [17]  on  a  type  system  with  effect  and 
resource  control  for  continuation  allocation.  While  the  state  resource  is  essentially  in¬ 
dependent  of  the  rest,  the  interactions  of  the  exception  resource  with  the  continuation 
resources  are  non-trivial. 

Although  we  do  not  present  the  semantics  in  terms  of  monads,  the  idea  to  use 
both  resources  and  effects  to  describe  a  function’s  interoperability  was  inspired  by  re¬ 
cent  work  on  monad-based  interactions  and  modular  interpreters  [21,  9,  20,  10],  and 
Wadler’s  work  on  the  relationship  between  monads  and  effects  [22].  Monads,  viewed 
as  compositions  of  basic  monad  transformers  [10],  can  be  used  to  represent  sets  of  re¬ 
sources.  The  transition  rules  creating  a  binding  activation  frame  and  binding  a  variable 
to  a  value  (Figure  12),  given  a  set  of  resources,  provide  the  semantics  of  the  ‘bind' 
and  unit  of  the  monad.  Resource-specific  primitives  are  interpreted  by  lifting  the  oper¬ 
ations  of  the  corresponding  monad  through  the  monad  transformers  enclosing  it  in  the 
composition. 

What  makes  our  approach  different  is  that  our  system  keeps  track  of  effects,  which 
allows  us  to  determine  which  components  of  a  monad  transformer  composition  are 
being  used  only  trivially  (i.e.  only  their  ‘bind'  and  unit  are  invoked)  and  therefore 
can  be  eliminated  or  simulated.  Furthermore,  we  wish  to  extend  and  reduce  the  set  of 
resources  in  a  commutative  way,  and  for  that  purpose  we  represent  the  result  of  trans¬ 
former  compositions  “horizontally”  -  the  corresponding  resources  are  collected  in  one 
component  of  the  abstract  machine  configuration.  Thus  if  the  set  of  resources  required 
by  term  e  corresponds  to  the  monad  M  =  (Tj  o  . . .  o  Tn)Id,  extending  it  via  usep  (e) 
is,  in  general,  not  expressed  as  an  application  of  a  monad  transformer  T  to  M,  but  as 
the  use  of  a  monad  morphism  [2]  to  embed  values  of  M  into  a  monad  isomorphic  to  a 
composition  of  7\, . . . ,  T,n ,  T  in  a  canonical  order.  Proving  the  equivalence  of  a  mon¬ 
ads  defined  as  compositions  with  their  horizontal  representations  meets  the  technical 
complexity  of  constructing  morphisms  between  them.  We  have  opted  instead  for  opera¬ 
tional  semantics  which  gives  a  more  direct  correspondence  with  an  implementation.  In 
our  semantics  the  complexity  of  lifting  monads  through  monad  transformers  is  reflected 


in  the  interaction  between  various  resources,  e.g.  in  transition  rules  (callcc),  (add),  and 
(block)  (Figure  13). 

Closely  related  to  our  work  is  the  research  on  effect  systems  [4,  7,  8,  18,  19].  The 
effects  in  our  system  are  used  for  verifying  interoperability  constraints;  in  this  context 
the  novel  bounded  effect  quantification  is  introduced  as  a  form  of  effect  polymorphism 
under  resource  restrictions  which  allows  us  to  take  advantage  of  the  effect-resource  re¬ 
lationship  to  support  advanced  compilation  strategies.  The  effect  inference  suggested  in 
the  typing  rules  in  Figure  8  is  conservative  and  there  is  considerable  room  for  improve¬ 
ment  borrowing  from  prior  work  by  e.g.  finer  separation  of  effects  and  adopting  region 
inference  or  for  determining  their  localization;  however  it  is  still  not  clear  to  what  ex¬ 
tent  this  improvement  will  materialize  in  practice  -  for  instance  the  exception  effects 
can  be  easily  localized  to  a  handler,  but  due  to  the  typical  extensibility  of  the  exception 
type  most  handlers  re-raise  exceptions.  We  intend  to  test  these  variations  in  a  prototype 
implementation  under  development  within  the  FLINT  system. 
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